The Push technology is a technology based on a client-server mechanism, in which the server actively sends information to the client. The Push technology is applied in the mobile Value-Added Services (VASs) to transfer relevant contents in time and to help users obtain the contents conveniently. The Push mechanism is a content distribution mechanism, and works in a client-server mode, in which the server distributes the contents desired by the client to the client without receiving a request from the client. FIG. 1 shows a Push service in the prior art. The service is initiated by a server. The Push Initiator (PI) who generates a Push message pushes information and transmits instructions to a Push Proxy Gateway (PPG), and the Push contents are further transmitted to the user by the PPG The system is composed of a PPG, a PI, and a terminal. The PPG obtains messages from the Push server through a Password Authentication Protocol (PAP), and sends the contents to a Wireless Application Protocol (WAP) user through a Push-Over The Air (OTA) protocol. The PI sends the Push contents and a transfer command to the PPG, and the PPG transfers the Push contents to the terminal according to the transfer command.
FIG. 2 shows a Session Initiation Protocol (SIP) Push service in the prior art. A SIP Push service is a Push OTA over SIP service defined by the Open Mobile Alliance (OMA), in which the Push OTA contents are encapsulated into a SIP message and transferred through the existing SIP/IP core network. SIP is an application-layer protocol for setting up a multimedia session between two or more participants. The PPG and the client act as interface points of the SIP/IP core network. In the SIP Push process, SIP can provide these functions: user reachability, user availability, user capabilities, session setup, and session management.
The SIP/IP core network provides plentiful end-to-end media sessions and sessions between the client and the server. The SIP/IP core network includes a SIP gateway and a registration server, provides the SIP client with service authentication and authorization, and provides SIP registration and routing functions. The PPG and the Push client are interface points to the SIP/IP core in function.
The SIP-based event subscription mechanism or the SIP event framework defines permission of notifying asynchronous events in the subscription process. After the initial registration, the Push client should send a SUBSCRIBE request to the PPG. If the Push client needs to subscribe to a Push event for a specific Push service, for example, transfer client capability information or subscribe to a specific event, the PPG and Push client are expected to support the SUBSCRIBE method and the NOTIFY method. Especially, the Push client should support the SUBSCRIBE function for specific Push contents, and support receiving of Push contents. The PPG should support the NOTIFY function, through which the SUBSCRIBE request is received from the Push client and the Push information is sent to the client.
A user ID is a public user identity. One or more public user identities are allocated for one user to use the network. When the user requests to communicate with another user, the user uses the public user identity. One user may have different appearances. Each appearance includes different public user identities. The format of a public user identity is a hierarchical SIP Uniform Resource Identifier (URI). The SIP URI may be constructed through a telephone number or a host name (such as SIP:user@company.com). SIP URIs are similar to email addresses, and therefore, easily correlated with email addresses of the user.
However, when a user has many terminals such as computers, 2G terminals or 3G terminals, the home network allocates a device ID to each terminal. The device ID controls uniqueness of each terminal in a network. For example, the device ID is used for authentication, authorization, and management.
The Push client may send a SUBSCRIBE request to update the subscription and declare available applications and versions through an “appid” parameter.
When the Push client subscribes to only one application, for example, “app 1” which is a Multimedia Message Service (MMS), the SUBSCRIBE request is as follows:                SUBSCRIBE sip user-aor@example.com SIP/2.0        Event: ua-profile; profile-type=oma-app; appid=“+g.oma.iari.Push.mms.ua”;        
When the Push client subscribes to multiple applications, for example app 1, app 2, app 3, the SUBSCRIBE request is as follows:                SUBSCRIBE sip user-aor@example.com SIP/2.0        Event: ua-profile; profile-type=oma-app; appid=“app 1, app 2, app 3”;        
If the Push client subscribes to app 1, app 2 and app 3 but the PPG supports only app 1 and app 2, then the NOTIFY message returned by the PPG includes only two parameters: app 1 and app 2, indicating that the two application services are subscribed to successfully. The SUBSCRIBE request and the NOTIFY message are as follows:                SUBSCRIBE sip:user-aor@example.com SIP/2.0        Event: ua-profile; profile-type=oma-app; ppid=“app 1,app 2,app 3”;        
NOTIFY                Event: ua-profile; profile-type=oma-app; appid=“app 1,app 2”;        
If a user has subscribed to the MMS, an MMS notification is sent to the terminal of the user once the PPG has an MMS destined for the terminal. The notification indicates that the user has an incoming MMS message and the user can retrieve it from the PPG. The user may set the terminal to retrieve MMS messages and store them on the terminal automatically, or the user retrieves the messages at convenient time after receiving the MMS notification.
In the SIP Push services, currently the same user may have a plurality of terminals. For example, a user has a 2G mobile phone, a 3G mobile phone, a desktop computer, and a notebook computer at the same time. The PPG stores the public user identity to identify the user. The PPG also stores the device addresses of the terminals for identifying the terminals so as to send the calls or messages destined for each device. The PPG also stores information about specific services that each terminal subscribes to.
When any service subscribed to by a plurality of terminals arrives, all terminals may receive the service. The services available for subscription include: MMS, Short Message Service (SMS), email notification, and device management. There is a scenario: When the PPG sends an MMS message to the user through the SIP/IP core network, each user terminal that has subscribed to the MMS receives a notification of the MMS message.
FIG. 3 is a flowchart of MMS communication when a user has a plurality of terminals in the prior art. When a user has a first terminal, a second terminal and a third terminal at the same time, the Multimedia Message Service Center (MMSC) is a PI, and the PPG is a PPG. The flow includes the following steps:
Step S301: The MMSC has an MMS notification message destined for the user, and sends the MMS notification to the PPG. After receiving the MMS notification, the PPG finds that the user has three terminals, and therefore, forwards the notification to the three terminals respectively.
Step S302: The user sets automatic retrieval of the notified MMS message, and therefore, the three terminals send a Hyper Text Transfer Protocol (HTTP) GET message to the MMSC PPG respectively, requesting to retrieve the MMS message.
Step S303: After receiving the GET message from the first terminal, the PPG sends an HTTP 200 OK response which carries the MMS message to the first terminal.
Step S304: The MMSC PPG deletes the MMS message that has been retrieved by the first terminal, and the second terminal and the third terminal receive an HTTP 4xx error response returned by the MMSC. The MMS notification may also be forwarded by the SIP/IP core network to the three terminals.
In the process of implementing the present invention, the inventor finds at least the following defects in the prior art:
Each terminal of the user receives the same MMS notification, which leads to a waste of resources and increases the network transmission load; moreover, the user has to receive the same information repeatedly. Even worse, the MMSC is unaware how many terminals are currently held by the user. After the MMSC sends a notification, the PPG or the SIP/IP core network forwards the notification to each terminal of the user. If the user sets automatic retrieval of the MMS message from the PPG, only one terminal can retrieve the MMS message successfully; the remaining terminals fail to retrieve the message, or the MMSC tells the user that the message does not exist or has been retrieved. Consequently, the user experience is deteriorated.